Atari Mega Archive 1/Atari Mega Archive - Volume 1.iso/lists/gem/l_0799/672

Internet Message Format | 1994-08-27 | 7.8 KB

Date: Sun, 3 Jul 1994 00:23:23 -0400 (EDT)
From: Timothy Miller <[e-mail]>
Subject: Re: Available Keyboard Keys
To: [e-mail]
In-Reply-To: <[e-mail]>
Message-Id: <Pine.3.87.9407030023.D5140-0100000@grad>
Mime-Version: 1.0
Precedence: bulk

Evan:


)  "Any key may use control.  Any key that is single-purpose, ie only one
)symbol on the key, may use shift-control."
)
)  T.Miller simply wants shifted and unshifted to be the same for single-
)purpose keys, which seems fine with the above statement.

I think, as usual, there is some miscommunication here.  For letter keys,
I want the letter in the menu to always be uppercase, and the shift key
to be shown explicitly.  I do NOT like implicit shift.  It looks ugly,
and it isn't obvious.  When most people see 'A' as something they have to
hit for some action, they do NOT press shift.  People are accustomed to
being able to just hit a key.  Most BBS's, for example, accept 'A' and
'a' for the same thing (in menus), and it isn't until you get to UNIX
where 'r' and 'R' are two different things which I think is kinda annoying.

There's nothing wrong with Shift-Ctrl-SOMETHING, but the shift must be
shown explicitly.  The SOMETHING should always be in upper case.

Also, if any multi-purpose keys are used, then shift should not be.
Like, on the US keyboard / and ? are on the same key, so Ctrl-/ and
Ctrl-? should be the same thing... no shift should be used.

But I agree that multi-purpose keys (ones that change from keyboard to
keyboard even more importantly) should not be used in the standard.

European and Hebrew characters can be used in menus and other things for
decorative purposes, but for nothing else.  We want everyone to be able
to hit every key combination.

Using 'level 1' isn't a sign of laziness.  Some of us have other things
on our minds besides key shortcuts.  If I were to write a wordprocessor,
I wouldn't even handle shortcuts until later in the design because I'd be
more interested in getting the word processor to process words, and then
I'd finally get all the shirtcuts hard-coded into the program.  By the
time I got all the rest of the user interface done, I wouldn't want to
have to take another week to interface with whatever arcane system is
being used for using shortcuts and making them show up properly in
menus.  That, I'm sure, would wait until the second release.

I am in strong support of making a standard that people are to use, and
if they don't follow part of it for some reason or other, they should be
certain to have a good reason.  If it's a good enough standard, then we
won't need a short-cut file with some annoying system for making it work
with my application, requiring more code and an added level or complexity
that I don't want to have to worry about when I have more important
things to do.  It's just one more piece of code, making the probability
of error and confusion just that much greater.  It's something that I'd
definately want to wait for the second release for.

I liked Ofir's new combination for close-window.  What was it, Ctrl-Esc
or something?  Whatever it was, it made sence.

You don't want counter arguements?  Well, I'm dreadfully sorry, but I
think this standard is very important, and when I disagree with you, I'm
going to say so.  I read the list and I consider every arguement
carefully, and then I make mine.  My ideas are no less valid than yours.

If dialogs are to use the same shortcuts as programs, how are we to enter
control keys into the dialogs?  Like a terminal program macro dialog or
search/replace in a wordprocessor.

I think OK and CANCEL buttons in dialogs should not be immediately next
to each other.  It would seem to me that someone (especially using a
track ball) might sslip and hit the wrong one.  Just a thought.


)  o  Avoid using the word "error" or any term which may blame the user.

)  o  Use 'Cannot' instead of "Can not' or 'Can't"

To these, I laugh.  Why did Atari specify these?  I suppose you'd want to
avoid pissing off the user, but some times errors really do occur, and
some times, things are REALLY the user's fault.  And what is so important
about the word 'cannot' that they have to put this in a guideline?  It
just seems silly to say not to use "can not" or "can't".


)  o  Open Desktop :  Construct a pop-up menu identicle to the GEM menu-bar
)  only vertical instead of horizontal and the top line should contain the
)  application name (like the desk menu). Attach the GEM menus as cascading
)  menus to this one, using the right arrow as normal.  If these menus in
)  turn have a sub-menu, then continue the cascade as needed, like a NeXT or
)  XWindows or something similar.  The user gains extra flexibility since
)  every menu available up top becomes available on any blank desktop space,
)  so users of big-screen monitors can trade some extra desktop space for
)  easier access to the menus.  Note that it may not be possible to re-create
)  the "desk menu" and allow the user to switch apps, but it would be nice.
)  Can we implement our own GEM message for this?  Just make the app top
)  a window and it will get the key focus, but how?

This should be part of the OS, not the application.


Yes, tell us about this third button.


There is enough disagreement on HOW blocks should be selected and handled
that I don't think we can standardize this.  Either way you choose
(unless someone comes up with a way to satisfactorily integrate the two),
someone will be pissed off.

However, concepts like OLE and Publish&Subscribe could be nice for us to
work on.

A general install application may not be a good idea.  Installs for
different applications always ask different questions.  We don't want to
require the user to install the parts of an app that he won't use just
for the sake of this standard.


You list Alt-Tab as Cycle-applications.  I thought the combination was
Ctrl-Alt-Tab or something like that.


Gem-List people:

How about I work on a way of combining the big-cursor and other
block-method into some compromise that everyone can accept?  Prepare to
compromise for youself, because it will contain elements of both
systems.  Additionally, since the two systems are generally incompatible,
it will certainly take more work to implementit.  My goals are:

o  Selecting blocks from the keyboard (independant cursor)
o  Selecting blocks from the keyboard (big-cursor)
o  Selecting discontinuous blocks from the keyboard (Indep-cursor)
o  Selecting blocks with the mouse (big-cursor)
o  Efficient handling of block-control shortcuts
o  Homogenious controls for blocks and normal text

In this case, something like Ctrl-A would select an intependant-cursor
block of the whole document.  If you select a block with the mouse
(click-drag), it becomes a big-cursor block, but if you slift-click-drag
for another block, both become independant-cursor blocks.

With independant-cursor blocks, cursor movement will not affect the
blocks, nor will normal typing, but Delete will delete the block.  Since
delete takes deliberation, even a single-level UNDO should be sufficient
to recover from any accidental erasures.

In this system, the user should be able to work as though he's using the
system be prefers with little adjustment (like a single block selected
with the mouse is automatically big-cursor).  This would also be good for
people who like to double-click on a word and replace it by just typing
in a new one.

I still think that Ctrl-A should not be Select-All, but under this
system, select-all would select an independant cursor block and not even
move the cursor from its original position.

Any suggestions about this should be sent to me privately in email.


I do agree with DMJ, though, that what kind of block-handling system is
used should NOT be specified by us, although hints and suggestions are
prefectly fine.